
SNA in Perspective: 1990 

It’s time again to weigh the past twelve months of SNA announcements and devel¬ 
opments, to perform SNA Perspective's annual rite of winnowing the wheat from 
the chaff. What sort of harvest was it? No single IBM communications announce¬ 
ment stands out in 1990—enhancements and progress were made in many areas. 

IBM surprised many during 1990 with its aggressive strategy in the area of commu¬ 
nications products, announcing new releases of VTAM and NetView, new versions 
of hardware connectivity products such as the 3172 and 3174, new architecture 
documents for peer communications, as well as another architecture-laden meta¬ 
product called SystemView. 

It seems appropriate, in a year that started with the fall of the Berlin wall, that IBM 
continued to march strongly toward more openness in SNA. SNA in the 1990s will 
not and cannot be confined to traditional SNA technologies. As just two examples 
of this increasing openness, SNA will run over Ethernet, Token Bus, and FDDI as 
well as Token-Ring and OSI can be encapsulated within LU 6.2 to run across SNA 

(continued on page 2) 


Where Will SNA Go in 1991? 


No year end issue would be complete without our scrambling out on a limb to 
deliver some prognostications on what the next twelve months may bring us. We 
divide these forecasts into two categories: 

• what we think may actually happen 

• what we would like to happen 


What You See Is What You Get 


Before we proceed, however, one expectation needs to be stated. Customers and 
competitors and, to some extent, government regulation in Europe, have been 
forcing IBM to announce its intentions and directions further in advance. Therefore, 
much of what was announced in 1990 has delivery dates in September and Decem¬ 
ber 1991. It is doubtful if IBM will deliver much in 1991 that hasn’t already been 

announced in 1990. , . , ox 

(continued on page 8) 
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backbones. IBM has also been aligning support 
between SAA and AIX and between NetView, 
SNMP, and CMIP, and began shipping OSI prod¬ 
ucts announced two years earlier. 

Crowning its 1990 announcements, IBM lifted the 
covers off the industry’s worst-kept secret, the 
S/390, a.k.a. Summit, series of mainframes. Over¬ 
looked by some in Summit’s shadow, IBM made 
several significant communications announcements 
in September, including a bow to improved host 
communications with the unveiling of the long- 
awaited fiber-optic ESCON channel. IBM also 
debuted, early in 1990, a major new midrange 
family, the RS/6000 running AIX, and significantly 
coordinated SAA and AIX support, elevating the 
importance of UNIX in the IBM operating system 
stable. 

The following are the hot topics and products in 
IBM communications for 1990 which SNA Per¬ 
spective has chosen to highlight in this year-end 
review. 

• SNA architectures and protocols 

- SNA over LANs 

- ESCON 

- LU 6.2 

- NT 2.1/APPN 

- LAN/Token-Ring 

- VTAM 

- Telephony 

• SNA hardware 

- 3174 

- 3745 

- 3172 

• Network management 

- System View 

- NetView 

- Multivendor Network Management 

• SNA multivendor network integration 

- OSI 

- TCP/IP 

- AIX 

• Cooperative processing and SAA 


SNA Architectures and Protocols 

The best place to start winnowing is with architec¬ 
tures and protocols. People often accuse IBM of 
causing TLA overload—too many three-letter 
acronyms. This isn’t entirely fair. True, IBM has 
been introducing many miscellaneous architectures 
for the last several years and continued this in 1990, 
but most have four letters. 

This can make it hard to see the forest for the trees. 
Compared to the relative ease of planting new 
sapling architectural trees, changing the SNA forest 
is a slow, incremental, evolutionary process. To see 
evidence of this, look at how long it has taken IBM 
itself to implement LU 6.2, which was announced 
in 1984 and is only, in 1990, making it into MVS 
and IMS. 

SNA Perspective believes IBM has been presenting 
these architectural tidbits in part to keep up interest, 
recognizing user disenchantment with SAA and LU 
6.2. Further, they serve to prop up subarea SNA in 
order to buy IBM time to complete the gargantuan 
task of preparing the new SNA (see Architect’s 
Comer in this issue). They also give us hints at the 
direction new SNA will take. 

SNA Over LANs 

1990 saw a major architectural shift when IBM 
announced a new version of VTAM that will allow 
SNA over Ethernet, Token Bus, and FDDI as well 
as Token-Ring. The new release of VTAM, VTAM 
3.4, in conjunction with the 3172 interconnect 
controller, will allow SNA packets to flow over 
Ethernet, Token Bus, and even FDDI. 

With this development, SNA will be able to pene¬ 
trate the engineering/scientific world, the factory 
floor, and anywhere that needs the 100 Mbps of 
FDDI. This was further evidence of IBM’s com¬ 
mitment to supporting multivendor networks. SNA 
Perspective believes this represents as profound a 
development as IBM’s announcement that SNA 
would incorporate Token-Ring LANs. 
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ESCON 

A second architectural change to SNA was the 
enterprise system connection (ESCON) channel 
architecture. Everyone knew that IBM was getting 
ready to replace the cumbersome bus and tag 
channels and their 1960s technology. As IBM itself 
put it in its announcement literature, ESCON is “the 
first major advance in channel architecture since the 
S/360.” 

The ESCON product line goes beyond just the 
channel connection. It also includes a family of 
matrix switches called the ESCON directors that 
provide high availability through nondisruptive 
recovery from failures in the channel or channel- 
attached devices. An ESCON director can support 
interconnection of several hosts and 3174 
controllers. SNA Perspective was pleased to finally 
see the arrival of ESCON. 

LU6.2 

1990 might be called “the greening of LU 6.2.” 

The year brought no major architectural enhance¬ 
ments to LU 6.2, although the LU 6.2 architecture 
documents ( LU 6.2 Reference: Peer Protocols and 
Transaction Programmer’s Reference Manual for 
LU 6.2) were updated to reflect prior changes. The 
principal LU 6.2 events of the year were more 
about product than architecture: 

• IMS/APPC at last gives to IBM’s main 
transaction processing application subsystem an 
implementation of IBM’s main transaction 
processing architecture. 

• APPC/MVS joins APPC/VM. 

• Reemergence of APPC’s two-phase commit in 
SAA’s common programming interface for 
communications (CPI-C). 

• LU 6.2 for NetView. 

• Remote distributed database architectures that 
rely on LU 6.2 transport. 

• Remote procedure interface (RPI) which uses LU 
6.2 to communicate between an OSI application 
on one system and an OSI/Communication 
Subsystem on another system. 


• NetBIOS LAN-to-LAN communication across 
SNA using LU 6.2. 

IMS/APPC—Although IBM promised for most of 
the latter 1980s that IMS’s support for APPC was 
just around the comer, it must have been the same 
comer behind which the ESCON channel was 
hiding. IMS/APPC was originally to have followed 
shortly after the CICS implementation in the mid- 
1980s. 

Two-Phase Commit—The reemergence of 
APPC’s two-phase commit is even more intriguing 
than the emergence of IMS/APPC. When IBM 
originally detailed CPI-C, it explicitly left out user 
access to the syncpoint option set in the underlying 
LU. Many analysts speculated on IBM’s motiva¬ 
tion behind this: Assuming that the LU and its 
option sets were implemented anyway, was the 
intent to keep the two-phase commit a proprietary 
interface so that IBM’s application developers 
would have an advantage over third-party competi¬ 
tors? IBM has laid this concern to rest with the 
announcement of what it calls the Resource Recov¬ 
ery Interface to the CPI. This was announced for 
the same release of IMS that has the basic APPC 
(IMS Version 3 Release 2) and also for VM/ESA, 
where it is called Coordinated Resource Recovery. 
Two-phase commit brings LU 6.2 closer in align¬ 
ment with the emerging OSI distributed transaction 
processing (DTP) standard. 

NT 2.1/APPN 

Moving from LUs to PUs, 1990 brought both good 
news and bad news about Node Type 2.1 (NT 2.1) 
and advanced peer-to-peer networking (APPN). 

The good news is the improved implementation of 
NT 2.1 in VTAM 3.4. Although VTAM currently 
supports independent LUs, many restrictions have 
until now limited the usefulness of the architecture. 

Additional good news is that the new release of 
VTAM, announced in September, will advance 
SNA’s progress toward allowing the interoperation 
of APPN networks using an intervening SNA 
backbone. Previously, VTAM had allowed an 
APPN network a single, static, predefined connec¬ 
tion to a subarea network. Now APPN networks 
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can have multiple, dynamic connections between 
themselves through an intervening SNA backbone. 

The bad news is that, despite this and other ad¬ 
vances, the new VTAM still does not incorporate 
any of APPN’s advances in dynamic route defini¬ 
tion and selection. Truly dynamic SNA did not 
materialize in 1990. 

IBM is starting to deliver on NT 2.1 and support for 
independent LUs. We hope for APPN, both as an 
architecture and as a product, in mainstream SNA. 
It’s important to remember that NT 2.1 and APPN 
are two different things. NT 2.1 is an architecture 
that IBM has defined and published. APPN, on the 
other hand, is a group of option sets for NT 2.1 that 
IBM has refused to designate as an architecture for 
reasons that are partly technical and partly legal. 
SNA’s architects are privately assuring major users 
that future releases of VTAM and NCP will incor¬ 
porate something very much like APPN’s dynamic 
route selection and directory services. But SNA 
Perspective believes such dramatic revision of SNA 
will not be announced until 1991 for delivery in the 
1992-1993 time frame (see Architect’s Comer in 
this issue). 

LAN/Token-Ring 

The principal development in IBM’s LAN strategy 
was the announcement that SNA will run over 
LANs other than Token-Ring. 

But IBM was not idle with the Token-Ring itself— 
it introduced a number of new products in 1990. 
These include the LAN-LAN Wide Area Network 
Program which, like the APPN enhancements to 
VTAM, allows for two LANs to have dynamic 
sessions over an SNA backbone. This product 
provides routing of encapsulated IBM NetBIOS 
packets over LU 6.2 sessions. 

IBM also renamed its LAN management products. 
Everyone knows of the confusion that resulted 
when IBM called its network operating system 
LAN Server (which is IBM’s version of the Micro¬ 
soft LAN Manager) and its management product 
LAN Manager. That’s been remedied; in 1990, 
IBM split it LAN Manager into two components— 
LAN Network Manager and LAN Station Manager. 


LAN Network Manager has been enhanced to work 
more effectively with NetView, including improved 
security and accounting management, and it now 
sports a graphical interface that is compliant with 
S AA’s common user access (CUA) standards. It is 
likely a sign of things to come in IBM’s network 
management that the LAN Station Manager con¬ 
forms to the OSI protocols for network manage¬ 
ment, supporting CMIP over LLC (CMOL). 

On the hardware side, IBM announced a controlled 
access unit (CAU), which allows up to eighty 
devices to be attached to the network. Because it is 
a powered device with local intelligence, a CAU is 
capable of executing security tasks and working 
with NetView. This is less an advance for IBM 
than a move that brings it to par with other Token- 
Ring providers. Still, the CAU does have some 
features its competitors lack. Most notably, it will 
work with both LAN Network Manager and LAN 
Station Manager. The CAU supports both copper 
and fiber and increases maximum distances for the 
lobes with built-in repeaters. 

VTAM 

The September announcements brought VTAM 3.4 
for MVS and VM, and VTAM 3.3 for DQS/VSE. 
Most of the major enhancements of VTAM 3.4 are 
addressed in this article under the categories that 
the enhancements affect. VTAM 3.4 will bring 
relief to many users trying to make their main¬ 
frames work more effectively in a nonhierarchical 
SNA environments with its enhanced support for 
NT 2.1 and for APPN networks. But, to many 
users, the biggest benefit in the new VTAM is its 
automation of many of the configuration manage¬ 
ment tasks of the VTAM systems programmers and 
operators—its ability to enroll self-identifying 
devices promises to dramatically cut down on the 
amount of work such personnel must do. As a 
further enhancement, IBM increased to sixteen the 
number of transmission lines supported between 
VTAM and NCP. 

The most significant of the remaining enhance¬ 
ments is dynamic network identification of 
switched and LAN devices. No one has ever 
accused VTAM of being easy to change. In fact, 
the old saw goes that if the phone system were run 
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the way VTAM was, everyone would have to hang 
up before a new user could be added. To a consid¬ 
erable degree, that is no longer so. In the new 
VTAM, new devices will automatically identify 
themselves to the network and be entered in 
VTAM’s tables without requiring a regeneration. 
For the MVS version of VTAM 3.4, this will go 
even further: working with the MVS I/O software, 
all devices that are channel-attached can identify 
themselves. 

Telephony 

An area where IBM took a large step back was its 
retrenchment in telephony. The sale of ROLM to 
Siemens muddied considerably IBM’s already 
muddled strategy for voice/data integration, and 
created a technological exposure that IBM may 
have difficulty covering with alliances. On the 
other hand, if it is a sign that IBM is focusing its 
efforts on doing a few things well, then the ROLM 
experience may be considered a timely, if expen¬ 
sive, lesson. 

SNA Hardware 

1990 did not see a lot of new SNA hardware. 

3174 

We got two new models of the 3174, local and 
remote controllers called the 21L and 21R in 
September, and a low-end version called the 
Tokenway 3174 in March. The 3174 family was 
also enhanced with support for the ESCON chan¬ 
nel. By connecting to an ESCON director, which 
can also be directly connected to up to eight main¬ 
frames, the 3174 can have direct access to multiple 
hosts. 

3745 

The 3745 had to be content with increased memory 
and a new, non-ESCON channel adapter using what 
IBM calls buffer chaining. The absence of an 
ESCON adapter for IBM’s major communications 
processor appears strange at first glance, but makes 
sense since SNA Perspective expects the 3745 to be 
made obsolete soon by a new “3765” family. 


3172 

The most interesting product from a hardware point 
of view is the new 3172 interconnect controller, 
introduced near the end of 1989 and first shipped in 
1990. The 3172, IBM’s newest communications 
box, is designed to replace the 8232 LAN channel 
station. It acts as a LAN-to-host channel gateway 
for Ethernet, Token-Ring, Token Bus, and FDDI 
and, alternatively, supports channel-to-channel 
connection. 

The 3172 is so well positioned that it has caused 
confusion among some users who have speculated 
that it may supplant the role of 3745s in running 
SNA networks. The strength of the 3172 lies in its 
extensive interconnection abilities. It cannot 
execute the immensely complicated subarea routing 
and flow control tasks of NCP, nor its boundary 
function tasks in support of APPN. The two are 
complementary, not competitors. The 3172 is 
discussed in detail under Reader’s Q&A in this 
issue. 

Network Management 

Ordinarily, the main news concerning IBM’s 
management products during 1990 would have 
been IBM’s announcement of two releases of a new 
version of NetView. But the hottest management 
news of 1990 was a new IBM initiative called 
System View. 

System View 

SystemView is a strategy for integrated total system 
management of multivendor heterogeneous envi¬ 
ronments. SystemView is not an architecture, nor 
does it have an underlying architectural basis. The 
strategy is defined in terms of three elements 
referred to as dimensions: end-use, application, and 
data. SystemView is described in more detail in the 
October 1990 issue of SNA Perspective. 

NetView 

IBM gave us some intimation of its future plans for 
network management by announcing two releases 
of a new version of NetView—Version 2 Release 1 
(to ship this month) and Release 2 (to ship in 
September 1991). 
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Release 1—Release 1 of the new NetView will 
bring three major innovations: 

• Support of NPM performance alerts 

• Support for linking NetView to IBM’s Systems 
management product, Info/Management, and its 
extensive databases of local, systems-specific 
data 

• A long-awaited graphics product, the NetView 
Graphics Monitor Facility (GMF) 

Unlike last year’s tactical graphics interface, GMF 
was developed by IBM and is an OS/2-based 
product that conforms to SAA’s CUA. 

Release 2—Users will have to wait until September 
1991 for NetView Version 2 Release 2 with: 

• Support for the new LAN Network Manager 

• LU 6.2 transport 

Multivendor Network Management 

IBM announced enhancements to its TCP/EP and 
OSI products that allow NetView to act as a focal 
point for management of TCP/IP, OSI, and SNA 
networks using NetView interfaces to simple 
network management protocol (SNMP) and com¬ 
mon management interface protocol (CMIP). This 
meets IBM’s statement of direction in this area. 

SNA Perspective sees this as an essential move if 
NetView is to carve out a niche as a multivendor 
network manager—NetView/PC was inadequate to 
the task. 

SNA Multi vendor Network 
Integration 

OSI 

In OSI, IBM prospered as it continued its steady 
march toward becoming a dominant participant It 
announced or rolled out OSI support for the main¬ 
frame (MVS, VM, VSE (RPI only)), midrange (AS/ 
400, RS/6000), and desktop (PS/2) platforms. This 
filled in a crucial piece of connectivity in its SAA 
puzzle. 


IBM’s 1990 announcements in OSI expanded its 
offerings both in breadth across the product line and 
in depth for the mainframe products in particular. 
OSI/Communications Subsystem (OSI/CS) is 
IBM’s implementation of OSI layers 3 through 6 
along with the association control service element 
(ACSE) from layer 7. OSI/File System (OSI/FS) is 
IBM’s version of the ISO File Transfer Access and 
Management (FTAM) standard. 

What IBM did in 1990 was ship OSI/CS for MVS 
and VM, meeting shipment dates set in September 
1988, and widen its OSI product line with versions 
of OSI/CS and OSI/FS products for the OS/2 and 
the OS/400 environments. At the same time, it 
deepened the functionality of the mainframe 
implementations of OSI/CS with Release 1.1 for 
both VM and MVS. OSI/CS 1.1, available now, 
adds three new areas of support: 

• Direct DTE-DTE connections 

• Ethernet attachment via the 3172 

• Remote OSI applications 

Direct DTE-DTE Connections—The mainframe 
implementations of OSI/CS (both VM and MVS) 
require (at least originally—see next bullet) that the 
lower OSI protocols be provided by the NCP packet 
switch interface (NPSI) software in a communica¬ 
tions controller. This combination allowed the host 
to function as an X.25 DTE and, as such, to com¬ 
municate with another OSI host over an X.25 
network. With OSI/CS 1.1, NCP 5.2 or higher, and 
NPSI 3.3 or higher, it is now possible to have two 
OSI/CS hosts communicate directly over a circuit 
switched line without any intervening DCE. 

Ethernet attachment via the 3172—Perhaps the 
most important thing about OSI/CS 1.1 is that it can 
now dispense altogether with using NPSI and the 
communications controller. By having a channel- 
attached 3172 connecting the OSI/CS host directly 
onto an 802.3 Ethernet LAN, very significant 
savings in cost (no need for a 3745) and execution 
time should accrue. The latter benefit stems from 
the fact that the channel to the 3745 is effectively a 
single-link SNA network, communicating with a 
“shadow” LU in NPSI, all of which is bypassed 
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when going to the Ethernet LAN directly. IBM 
intends to add support for OSI over Token-Ring 
and Token Bus as well. 

Remote OSI applications —An OSI application 
can now run on an SNA host without OSI commu¬ 
nications capability and communicate with an OSI/ 
CS host via an LU 6.2 session. To do this, both 
hosts must run VTAM with the optional OSI 
remote programming interface (RPI) feature 
announced in June 1990. OSI RPI can be consid¬ 
ered as a client/server split, with the OSI applica¬ 
tion on the “client” system making calls, which are 
intercepted by OSI RPI as remote procedure calls 
and transported via LU 6.2 across an SNA network 
to a “server” system which does have OSI/CS. 

VSE was one system for which RPI was introduced 
where OSI/CS is not supported. Now that IBM 
appears to be making VSE a quasi-SAA platform, 
the company seems to be saying this is the avenue 
they will use to provide OSI connectivity for VSE 
hosts. Undoubtedly, this is to avoid delivering a 
third mainframe implementation of OSI/CS itself. 

In addition to the OSI/CS and OSI/FS products, 
IBM also announced a reworking of its X.400 store- 
and-forward messaging software, now called Open 
Network Distribution Services (ONDS). The new 
software will have ties through X.400 PROFS 
Connection and X.400 DISOSS Connection into the 
messaging systems for Office Vision as well as 
DISOSS and PROFS. IBM’s X.400 ONDS, in 
conjunction with OSI/CS, supports two OSI mes¬ 
saging systems communicating with each other 
over SNA via an LU 6.2 session, or across Ethernet 
or X.25. 

TCP/IP 

To most users today, multivendor network integra¬ 
tion defaults to TCP/IP and will continue to do so, 
at least until OSI matures and a variety of OSI 
products are available, and likely long past that. To 
capture this market, IBM has implemented TCP/IP 
protocols on its strategic platforms. 

At the beginning of the year came TCP/EP for OS/2, 
which will allow the PS/2 platforms to interoperate 
in the engineering/scientific world. In June, TCP/IP 


Version 2 for VM was introduced, followed in 
September by TCP/IP Version 2 for MVS. TCP/IP 
Version 2 is designed to enhance the capabilities of 
the S/3x0 as a server in an engineering/scientific 
environment and includes: 

• X Windows support 

• FDDI connection via the 3172 

• Management from Net View Version 2 with the 
SNMP 

An insight into IBM’s strategy toward TCP/IP can 
be gleaned from the emphasis it gave to migration 
support for moving to OSI. IBM’s strategic com¬ 
mitment is to OSI; TCP/IP had been viewed merely 
an intermediate step along the way. But IBM is 
realizing that the intermediate step is larger and 
longer than anticipated, especially with its stepped 
up participation in the UNIX world with its RS/ 
6000. IBM is thus is forced by customer demand to 
provide more significant TCP/IP support than it 
originally expected. 

AIX 

In February, when IBM introduced the RS/6000 
family of RISC-based workstations and servers, it 
also unveiled a new version of IBM’s UNIX 
operating system for them, AIX Version 3. In 
addition to the RS/6000, AIX runs on IBM’s PS/2 
and S/3xQ mainframes. 

IBM also took this opportunity to make several 
statements of direction on communications between 
its various operating systems and operating envi¬ 
ronments, its network management protocols and 
systems, and its distributed files and applications. 
IBM made it clear that AIX is nor joining the SAA 
family. However, IBM called both SAA and AIX 
its two strategic computing environments and stated 
that interoperability between SAA and AIX is 
essential. 

Cooperative Processing and SAA 

Last, but not least, we come to IBM’s announce¬ 
ments in cooperative processing, which IBM has 
formalized in its Systems Application Architecture 
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(SAA). If votes were cast in 1990 for the hottest 
buzzword, the winner would have to be client/ 
server computing, which is one type of cooperative 
processing. 

SAA was the hot topic of 1989, withthe announce¬ 
ment of Office Vision, the first major SAA applica¬ 
tion. But in 1990 SAA took on a new flavor. 

IBM’s current claim is that cooperative transaction 
processing rather than application portability is the 
prime raison (Pitre for SAA. Major delays were 
announced for OfficeVision, many feature exten¬ 
sions were made to SAA, and VSE and Windows 
3.0 appear to be becoming quasi-SAA platforms. 

IBM announced a number of SAA’s pieces such as 
the OSI software and assorted compilers. From the 
communications perspective, the most important 
news was, of course, that the CPI was enhanced and 
two-phase commit surfaced as a user-accessible 
service in the form of the resource recovery inter¬ 
face announced in September. 

An unfortunate note was struck over SAA’s princi¬ 
pal showcase, the Repository Manager, when it was 
discovered that the entity-relationship model used 
by the Repository’s developers for representing 
internal data had not been adopted by the Sys¬ 
tem View architects. Instead, they chose to imple¬ 
ment the OSI standards on object definition as 
specified in the ISO standard Guideline to the 
Definition of Managed Objects (GDMO). 
Undoubtedly IBM will fix this but it is not an 
auspicious beginning. 

One of the sleepers of 1990 was user pressure on 
IBM to let Windows 3.0 become an SAA environ¬ 
ment for the PS/2 platform. This pressure from 
major users unwilling to move to OS/2 highlights a 
danger to the SAA effort The fatal flaw lurking 
within any effort as expansive as SAA is that the 
search for the best approach can kill off all the 
viable alternatives in favor of an unattainable ideal. 
Whenever SAA is expanded to include more 
architectures and/or more platforms, the chances of 
delivering it in an acceptable time frame, or even at 
all, are diminished. 


Distributed Computing 

IBM made several moves to lay an architectural 

groundwork for distributed computing in 1990. 

OSF DCE—IBM together with Digital Equipment 
Corporation and Hewlett-Packard, among others, 
sponsored a proposal called DEcorum to the Open 
Systems Foundation (OSF) for a distributed com¬ 
puting environment (DCE). Significant portions of 
this proposal were accepted by OSF. DCE includes 
several technologies, among them a remote proce¬ 
dure call, name service, directory service, time 
service, multithreading, authentication/security, 
distributed file system, PC integration, and diskless 
operation. 

Supporting Architectures—In July, IBM made 
five announcements related to remote distributed 
relational data architectures. These included an 
extension to its SAA CPI and four extensions to its 
SAA common communications support (CCS) (see 
SNA Perspective August 1990). In September, IBM 
had several SAA-related announcements, most of 
which revolved around distributed relational data, 
transaction processing, database integrity, and 
system management. To architecturally formalize 
these extensions, a new resource recovery service 
was added to the SAA CPI, and CPI-C and SQL 
were enhanced. Together with the July announce¬ 
ments, they largely complete the SAA remote 
distributed relational data scheme, which was 
originally unveiled in October 1988. 

Analysis 

Lost in the Rush 

In 1990, IBM announced the more products than in 
any other year in its history. As a result, some of 
the most significant communication announcements 
got lost in the rush. 

IBM is Listening 

SNA Perspective believes that the 1990 announce¬ 
ments show IBM’s professed willingness to listen 
to customer input is more than just a talking point 
in closing sales. The challenge is to decipher where 
talk leaves off and products begin. The plethora of 
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1990 announcements leave IBM’s competitors and 
customers wondering if behind the smoke there is 
sufficient fire to deliver on the promises, given 
IBM’s lumbering product development cycle. 
Notwithstanding its prolific announcements, IBM 
admits it is suffering from long development 
schedules. Much of what was announced in Sep¬ 
tember 1990, for example, has delivery dates as late 
as December 27,1991, and it is doubtful if IBM 
will deliver much in 1991 that hasn’t already been 
announced in 1990. 

On the other hand, IBM is also using long lead 
times to respond to customer demand to understand 
where the company is headed so they can take it 
into account in their long-range planning. And 
although 1990 was the year of the Office Vision 
delay, it was also the year IBM delivered OSI/CS 
for MVS and VM in the month scheduled at their 
September 1988 announcement. 

Where did SNA Go in 1990? 

The most significant IBM communications trend in 
1990 was its increased openness to multivendor 
networking. The two major SNA steps forward 
were the ESCON channel and SNA over alternate 
data links. With these two exceptions, the architec¬ 
ture of SNA itself did not move much. But that’s 
alright: far better that IBM produce what it has 
already architected than produce sweeping new 
architectures. Whether IBM will be able to meet its 
ambitious schedules for all the new products is a 
question that remains. ■ 


SAA Environments 

T ransaction-based environments 
OS/2 EE for PS/2 
OS/400 for AS/400 
IMS/ESA TM for S/3x0 
CICS/ESA for S/3x0 

Interactive application environments 
OS/2 EE for PS/2 
OS/400 for AS/400 
CMS for S/3x0 using VM/ESA 
TSO/E and APPC/MVS for S/3x0 using 
MVS/ESA 

“VSE/ESA supports SAA transaction processing 

with CICS/VSE” 


(Continuedfrom page 1) 


What We Don’t Expect 

1991 will likely be more quiet than 1990 for IBM 
communications. For example, VTAM 3.4 will not 
be released until September 30,1991, so it is 
unlikely that IBM will announce yet another 
release. If there were a release (there have been 
eight releases of VTAM in the last nine years), it 
would probably be VTAM 4.0, not VTAM 3.5; 

IBM has never gone to x.5 in a VTAM release. 

Still, SNA Perspective expects VTAM 4.0 in 1992, 
which will fundamentally incorporate APPN, as 
will new SNA, which we expect to be announced in 
1991. 

What SNA Perspective Expects 

Further SNA/OSI Convergence 

The clear trend that IBM is pursuing is to enhance 
SNA while it tracks OSI developments. SNA 
Perspective believes that IBM has clearly made a 
strategic decision to forego some advantages of a 
proprietary SNA for the market benefits of produc¬ 
ing what an increasing number of its largest con¬ 
sumers want. In other words, IBM is gradually 
folding OSI into SNA, replacing or at least aug¬ 
menting SNA protocols with OSI protocols as they 
become international standards. Two areas in 
particular stand out as candidates for such change in 
1991: 

• Full-duplex APPC 

• CMIS/CMIP incorporation into NetView 

Full-duplex APPC means full-duplex LU 6.2 
sessions and conversations. This would support 
optimizing LU 6.2 for interactive use and real-time 
applications while it is currently an asynchronous 
protocol designed for store-and-forward between 
applications. SNA Perspective believes that IBM 
will announce new implementations of APPC that 
are full duplex, at least at the session level, to more 
closely align LU 6.2 with the ISO standard on 
transaction processing. (See SNA Perspective July 
1990 for more details on LU 6.2 vs. OSI distributed 
transaction processing (DTP) protocols). Those 
who have seen IBM’s architecture documents for 
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LU 6.2 confirm that the capability to have full- 
duplex sessions and conversations has been in the 
architecture from its inception. As LU 6.2 has been 
implemented, however, there is no provision for 
either, and users are confined to half-duplex flip- 
flop (HDX FF) sessions and conversations. Since 
the OSI DTP is likely to become accepted as a full 
ISO international standard in 1991, IBM may chose 
to announce that LU 6.2 will move toward compli¬ 
ance with the standard, or it may announce that LU 
6.2 will comply with the implementor workshop 
profiles on which work is proceeding concurrently 
with the standard ballot process. 

CMIS/CMEP support is already part of IBM’s 
open network management strategy. However, 

SNA Perspective believes that IBM is going beyond 
allowing NetView to manage OSI networks and is 
moving toward adapting NetView internally to 
conform more closely to the OSI model. New IBM 
products to be announced in 1991 will likely use the 
OSI protocols for exchanging network management 
data and commands. 

“3765” 

A “dog that didn’t bark” in the September 1990 
product announcements was the absence of an 
ESCON adapter for the 3745 communications 
controllers (although IBM issued a statement of 
direction to supply one). The most likely reason for 
this delay is that the 3745 is destined for replace¬ 
ment in a timeframe that obviates the need to 
develop an ESCON adapter for it The expected 
“3765” replacement, which IBM hinted at during 
the November GUIDE meeting, will be based on a 
new hardware architecture that supports much 
higher performance and is better suited to support 
the demands of APPN. 

More TCP/IP Announcements 
If OSI is the new king of multivendor networking, 
then the old king TCP/IP is a very lively cadaver. It 
is beginning to look as though the cutover from 
TCP/IP to OSI may take longer than anyone 
expected several years ago. Expect IBM to respond 
to market conditions by augmenting its TCP/IP 
offering even more, especially in the area of net¬ 
work management A recent agreement between 


IBM, MCI, and Merit to develop management tools 
for the NSFnet may be one motivation. 

Performance Management 
Automated performance management is the final 
frontier of network monitoring and control. Per¬ 
formance management is much more complex to 
address than problem management yet the need for 
it is rising as networks are under increasing pres¬ 
sure to maximize return on investment. SNA 
already has an automatic control system in place for 
managing congestion of virtual routes in a subarea 
network, namely RPacing. 

SNA Perspective believes that IBM will announce 
in 1991 a performance management tool that will: 

• be completely integrated into NetView (unlike the 
Network Performance Monitor it will supplant) 

• allow for automation of many routine operator 
tasks involved in load balancing and traffic 
management 

The S/390 announcement and the dynamic registra¬ 
tion will show the savings in personnel and operat¬ 
ing costs that come from task automation. SNA 
Perspective believes that IBM is committed to this 
direction. We also think that performance manage¬ 
ment, with its complex decision making and real¬ 
time requirements, will be IBM’s choice for an¬ 
nouncing an automated management package, 
possibly including expert systems technology. 

What SNA Perspective Would Like 
to See in 1991 

Dynamic Alternate Routing in Subarea SNA 
If IBM can make VTAM dynamically register 
devices attached to the host, can’t it make SNA 
routing resemble that of APPN? This will allow 
SNA, if a path fails, to automatically assign a new 
session. No one knowledgeable about VTAM 
would claim that this will be a simple task, but it is 
nonetheless a vital one if SNA is going advance 
into the 1990s. 
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Formalize “Casual Connections ” 

Casual connections are a quick and dirty kludge to 
support peer-to-peer networking on a subarea basis. 
SNA Perspective would like to see them formalized 
and rationalized, which will probably be part of 
new SNA. Independent LUs are another interim 
solution to peer communications in an SSCP-LU 
session the way that casual connections deal with 
the SSCP-PU session. Enhancements here would 
also be appreciated. 

Application Management 

Currently, IBM’s management tools use a non- 
architected protocol boundary to move information 
from an SSCP-LU session to the SSCP-PU session 
so that it can be transmitted and therefore managed. 
Response Time Monitor works this way, for 
example. With LU 6.2 for Net View, moving to less 
of a kludge solution to monitor functions of appli¬ 
cations would be possible so that information on an 
SSCP-LU session can be directly monitored. 

NT 2.1 Support in 3174 

One of the most popular configurations for connect¬ 
ing mainframes to Token-Ring networks is using a 
local (channel-attached) cluster controller with a 
Token-Ring interface attachment. This configura¬ 
tion, however, presents users with a dilemma. 
Because the 3174 lacks the NT 2.1 control point, it 
is impossible to have APPN sessions up to the host. 
Why has IBM been so reluctant to implement NT 
2.1 in the 3174? Possibly the 3172 decreases the 
need for this enhancement for local controllers, 
though this lacking could limit the lifespan of the 
3174. 

SNA OverSMDS, B-ISDN 

Public data networks didn’t take off in the United 
States to the extent they did in Europe, evidenced 
by the pervasiveness of X.25 in Europe compared 
to the United States. This is changing somewhat as 
the regional Bell operating companies aggressively 
move into value added and public data networking. 
Two technologies are spearheading their drive: 
switched multimegabit data service (SMDS) and 
broadband ISDN. IBM must position SNA to run 
over these and similar services, such as frame relay 
and fast-packet. The announcement of SNA over 


non-SNA LAN technologies is a promising start, 
but will IBM be able to do it for WANs without 
ROLM’s telephony expertise? 

Non-Mainframe Focal Points 
SNA networks will be able to be managed from 
non-IBM systems, including Digital (through its 
agreement with Systems Center) and Tandem. SNA 
Perspective believes that IBM may even choose to 


announce a NetView focal point on the RS/6000, 
which we believe has the technical capability to 
support it ■ 

1990 IBM Communications 
Announcement Highlights 

February 

RS/6000 

AIX3.0 

SAA/AIX alignment 

March 

Tokenway 3174 controller 

May 

OSI/CS ships, as announced in 
September 1988 

June 

Multivendornetworking 
barrage Part 1 

OSl position paper 

OSIRPI 

OSl for RS/6000 

TCP/IP V.2 

NetView for SNA, OSl, TCP/IP 
from one console 

July 

SAA remote distributed relational 
data architectures 

9/5 

System/390 ES/9000 main¬ 
frames (Summit) 

ESCON channel architecture 

VTAM 3.4 

NetView 2.1,2.2 

SystemView 

APPC for IMS and MVS 

3172 enhancements 

9/18 

Multivendornetworking 
barrage Part II 

OSl for OS/2, OS/400 

TCP/IP MVS and NetView 

X.400 and ONDS 

SNA over Ethernet 
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Reader’s Q & A 


An SNA Perspective reader from AT&T recently 
asked us about the significance of the IBM 3172 
interconnect controller. In particular, he wanted to 
know what it signified for the future of the IBM 
3745 communications controller. 

What It Is 

The IBM 3172 interconnect controller was designed 
primarily as an interface between IBM hosts and 
LANs, particularly with Ethemet/802.3 LANs 
running TCP/IP and MAP/802.4 LANs running 
OSI. However, through enhancements announced 
in September 1990, IBM is increasing the 3172’s 
Token-Ring and SNA support. In addition, the 
3172 will support FDDI, host-to-host channel 
connectivity (via T-l and the new ESCON architec¬ 
ture), and IBM has said it will later support a T-3 
interface. 

3745 Limitations 

The 3745 is hardware-constrained in performance 
when interfacing to high-speed LANs and WANs. 
This constraint was eased somewhat in September 
with the buffer chaining channel adapter (BCCA), 
which improves host-controller performance. Also, 
the memory was increased fifty percent, which 
helps support the dynamic LU definitions required 
to support node type 2.1. However, these are 
patches to a limited hardware architecture. 

Further, developing an interface adapter for the 
3745 (or any proprietary architecture) is an exten¬ 
sive process involving several person-years of 
investment. The 3172, on the other hand, is based 
on IBM’s Micro Channel Architecture, so that 
third-party adapters designed for the PS/2 to 
connect to all types of LANs can easily be adapted 
for the 3172. IBM would rather not invest its R&D 
dollars into commodity hardware development 


Newer protocols today handle many of the func¬ 
tions that communications controllers used to 
perform. For many years, companies have been 
replacing SDLC communications locally with 
LANs and remotely with X.25 and T-l networks, 
which can also support other protocols in addition 
to SNA. These changes significantly affect the role 
the communications controller will play. The 
strength of the 3172 lies in its extensive intercon¬ 
nection abilities. It cannot execute the immensely 
complicated subarea routing and flow control tasks 
of NCP nor its boundary function tasks. The two 
are complementary, not competitive. 

NT 2.1 for 3174? 

Peer communications could be improved by IBM 
adding NT 2.1 support to the 3174 cluster control¬ 
ler. However, we no longer believe that this will be 
IBM’s strategy to support LAN-to-host communi¬ 
cations, although IBM may still eventually so 
enhance the 3174. It is interesting to note the simi¬ 
larity in numbering of the 3172 and 3174. 

3172 Positioning 

The 3172, originally intended only to support 
multivendor LANs (Ethernet with TCP/IP and 
MAP with OSI), has been elevated as IBM’s option 
of choice for interfacing LANs to hosts. This is 
part of a pattern SNA Perspective has seen emerg¬ 
ing, which it described in May 1990 “SNA Moves 
from WAN to Extended LAN,” which is the 
extension of networks operating at layer 2 so that an 
increasing percentage of the physical network is 
independent of the upper-layer information and 
protocols it is sending. 

“3765” on the Horizon ? 

SNA Perspective believes that IBM will unveil a 
replacement for the 3745 in 1991 which will be 
based on a new hardware architecture that can 
better support new SNA functionality. This new 
communications controller family, which IBM 
hinted at in the November GUIDE meeting, will 
likely not ship until 1992. Because of this new 
family, SNA Perspective does not expect significant 
enhancements to the 3745. The new communica¬ 
tions controller will likely be based on the Micro 
Channel Architecture, and may include other 
architectural similarities to the 3172. ■ 
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IBM 3172 Interconnect Controller 

Introduced in October 1989 and first shipped in September 1990, the 3172 is a Micro Channel-backplane 
gateway based on the 386 (model 1) or 486 (model 2) processor, but with a different BIOS than the PS/2. It 
replaces the 8232 LAN Channel Station. 

The 3172 is run from a PS/2 running OS/2 EE 1.2 and the 3172 operator facility software, which is provided 
with the 3172 interconnect controller program. This PS/2 can manage up to sixteen 3172s via a Token-Ring 
LAN. The 3172 can be managed by NetView. It operates as a Node Type 2.1 and supports LU 6.2 communi¬ 
cations. 

3172 Model 1 

At the October 1989 announcement, the 3172 was introduced to support: 

• LANs—Token-Ring, Ethernet/802.3, and MAP (broadband and carrierband) 

• Host protocols/environments—TCP/IP for VM, MVS, and AIX, and MMS for MAP 

The September 1990 announcements added: 

• SNA application communications added for Token-Ring, Ethernet and MAP LANs (requires VTAM 3.4) 

• Support for the IBM PC Network added for connecting to TCP/IP on VM and MVS (available 12/91) 

• Local channel-to-channel (CTC) support via the new ESCON adapter (available12/91) in addition to the 
existing parallel channel (requires VTAM 3.4. ESCON adapter does not support LAN-to-host.) 

• Remote CTC support via T-1 adapters (available 12/91) 

• Support for OSI/CS communications across Ethernet through the 3172 

The base price of the 3172 model 1 is $15,450. The LAN adapters are priced from $315 (PC Network 
baseband) to $2,495 (MAP broadband). The parallel channel adapter costs $7,500 and the ESCON adapter 
will cost $11,500. The T-1 adapter costs $3,057. 

Each 3172 can be used either for CTC communications or for LAN-to-host communications. Each 3172 can 
support up to four LAN attachments and two channel attachments. 

3172 Model 2 

The 3172 model 2 uses the 486 processor and supports the 100 Mbps fiber distributed data interface (FDDI) 
LAN. It supports TCP/IP and SNA data flows between the FDDI LAN and the host. Scheduled availability for 
the 3172 model 2, priced at $48,500, is December 1991. It currently does not support any other LANs nor the 
new ESCON channel architecture. 

3172 Statement of Direction—September 5,1990 

• Enhance model 2 to support: 

- access to SNA applications through VTAM for Token-Ring and Ethernet LANs as well as FDDI 

- access to TCP/IP VM and TCP/IP MVS for Token-Ring, Ethernet, and PC Network LANs as well! as FDDI 

- host remote CTC support with DS-3 (T-3) links 

- remote CTC for model 2 via ESCON channel adapter 

• Add OSI/CS support to Token-Ring, Ethernet, FDDI (model 2 only), and MAP (model 1 only) LANs 
(OSI/CS support over Ethernet was announced on September 18.) 

• Enhance centralized change and configuration management capabilities, supporting NetView Distribution 
Manager and NetView’s Network Asset Management functions 
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LU 6.2 User 
Acceptance—Part II 

Organizations that have implemented logical unit 
6.2 (LU 6.2) in their SNA networks in the last few 
years have not embraced it wholeheartedly. Many 
have found it too complex to expand further but 
most are waiting for applications. 

This article is the second part of a two-part series 
on user acceptance of LU 6.2. SNA Perspective 
followed up with companies that, three years ago, 
had plans to implement LU 6.2. The first install¬ 
ment, “LU 6.2 Growing More Slowly Than Antici¬ 
pated” in September 1990 SNA Perspective, fo¬ 
cused on those organizations that had not followed 
through on their initial plans. This article will 
examine the experiences of those who have 
implemented LU 6.2. 

Where We Looked 

In August 1987, SNA Perspective did an extensive 
survey of SNA users to determine the extent of 
LU 6.2 penetration and the potential market. At 
that time, less than twenty percent of the survey re¬ 
spondents had implemented LU 6.2. Of the remain¬ 
der, about one-third had plans to implement it 
within two to three years, another third intended to 
start using it in three to four years, and the rest had 
no plans to use LU 6.2. 

That survey concluded, based on respondent 
enthusiasm, that by 1991 three-quarters of all SNA 
users would be implementing LU 6.2. Current 
feedback indicates that the growth curve has been 
less steep than even the customers themselves 
expected. 

Three years later, SNA Perspective followed up 
with those who indicated that they would imple¬ 
ment LU 6.2 within two to three years. Note: This 
follow-up research was not a statistical survey but, 
rather, a sampling of the respondents to the first 
survey. Therefore, the results are given in qualita¬ 
tive rather than in quantitative terms. 


Only one-third of those we contacted have followed 
through on plans to implement LU 6.2. All results 
in this article (unless otherwise specified) refer to 
these implemented. The non-implementers were 
discussed in the previous article in September 1990 
SNA Perspective. 

What We Found 

Systems and Environments 

Some respondents have implemented LU 6.2 only 
on their midrange systems, either AS/400s or 
System/36s, even though most also have 3090s on 
site. 

Of those who have LU 6.2 on their mainframes, 
most have 3090s. None of the mainframe imple¬ 
mented have LU 6.2 also running on IBM 
midrange systems (though some support LU 6.2 to 
other vendors’ midrange systems). Most of these 
mainframe systems are running MVS/XA or MVS/ 
ESA. Most are operating at VTAM 3.2 or 3.3 and 
NCP4.3 or 5.2. 

Most have included personal computers in their LU 
6.2 environment, with approximately equal num¬ 
bers supporting DOS or OS/2 systems. Some use 
packaged products, for example from Spectrum 
Concepts or Orion. Others have developed home¬ 
grown applications using APPC/PC or OS/2 EE 
Communications Manager. 

About half of the implemented use LU 6.2 in a 
CICS environment. Some have implemented it 
under VTAM. Some have developed completely 
homegrown LU 6.2 environments. Several have 
done more than one of these. 

The majority are using LU 6.2 to communicate with 
a remote site, with a few using it only for that 
purpose. 

Applications 

Most applications relate to the organization’s line of 
business, such as security and loan servicing for 
banks or inventory for manufacturing. File transfer 
and database concurrence are the most common 
types of transactions. 
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Pilot/Operational 

The majority of sites report that their LU 6.2 
implementation is operational; the others still 
consider it a pilot program. Most have had LU 6.2 
implemented for a year or two. The length of time 
it has been installed had no beating on whether the 
user still considered it a pilot project. 

Expansion Plans 

Few sites responded that LU 6.2 was a standard for 
their network. 

Expansion plans include adding: 

• LU 6.2 to midrange systems 

• PC-to-host LU 6.2 connectivity 

• New environments (such as IMS) 

• Device-to-deviee support (in addition to program- 
to-device support) 

Half of the respondents have no plans to expand 
LU 6.2 usage. They reported they could see no jus¬ 
tification for increasing LU 6.2 for its own sake, 
and they saw no applications on their horizon that 
required it. 

Implementation Challenges 

Complexity and lack of features, functions, and 
applications were cited as the most significant 
challenges faced in adding LU 6.2. Cost was rarely 
a major concern. Respondents also reported that 
management was very supportive of their implem¬ 
entation efforts. 

Those with multivendor systems reported problems 
with differences between the vendors’ LU 6.2: 
different terminology, definitions, features, and 
restrictions. 

Several commented on training complexity and the 
difficulty of the staff in adjusting to the mind-set of 
a whole new ballgame in peer rather than batch 
communications. The lack of staff who understand 
what LU 6.2 really means is decreasing the motiva¬ 
tion to increase LU 6.2 usage. One respondent 
stated that “some off-the-shelf applications are 


available, but the user still must be familiar with 
LU 6.2 to succeed.” 

Benefits 

Most respondents were able to point to clear bene¬ 
fits from their LU 6.2 implementation, including: 

• Balance of resource usage 

• Coordination of databases 

• Improved performance 

• Cost savings 

• Well-architected solution 

• Transparency 

• Portability 

However, some of these respondents noted that 
these benefits could not obviously be leveraged to 
other applications. Some improvements related to 
what was used before (LU 0 to LU 6.2), or to the 
ease of using a commercial product which required 
no NCP sysgen changes. Finally, the respondents 
did not indicate that the benefits were significant. 

Conclusions 

From the results of this research, it seems clear that 
IBM faces tremendous challenges with LU 6.2 and 
with moving SNA to peer-to-peer communications. 
Most users are not convinced that they should make 
the move. And those who are convinced find it a 
difficult move. 

SNA Perspective believes that LU 6.2 is a signifi¬ 
cant element for the future of SNA. User accep¬ 
tance of LU 6.2 as part of a move to peer-to-peer 
communications is essential to IBM’s strategy if 
SNA is to survive to the end of the century as a 
strong contender. 

However, IBM has been less than successful in 
promoting LU 6.2 to its SNA user base. Most SNA 
network planners are aware of LU 6.2 and of how 
excited IBM is about it, but the excitement has not 
been contagious. 
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One respondent summed it up by saying “I haven’t 
implemented LU 6.2 because IBM didn’t do what it 
said it would do (three years ago), though it is just 
now beginning to follow through. To convince 
users to implement LU 6.2, IBM needs diverse 
products, a methodology to implement, and to work 
with partners to encourage more applications.” 

Applications Needed 
Those who have not yet implemented LU 6.2 
repeated over and over that there were no applica¬ 
tions they needed that required LU 6.2. Even those 
who have implemented it are expanding its usage 
slowly because of the dearth of applications. 

In 1990, a year we could refer to as “the greening of 
LU 6.2,” IBM finally announced several environ¬ 
ments, products, and architectures based on LU 6.2, 
including, but not limited to, LU 6.2 for IMS, LU 
6.2 for Net View, LU 6.2 as the underpinning for 
remote distributed relational data architectures 
(DRDA and CDRA), APPC/MVS, and LU 6.2 for 
OSI and NetBIOS encapsulation across SNA. 

Many of these will not be available until late 1991 
and off-the-shelf applications taking advantage of 
them will take us into 1992. So users still find 
themselves in a holding pattern. However, at least 
the planning horizon is more definite. 

Complexity Hurdle 

Many respondents reported disappointment with the 
complexity of adding LU 6.2. This included 
problems with vendor support and staff training as 
well as the architectural and development hurdles, 
since so much needs to be done in-house. 

More off-the-shelf and semi-custom applications 
will reduce many of these challenges. IBM could 
also focus on providing more support for those 
customers who take on the challenge of implement¬ 
ing LU 6.2 by rewarding them for moving down 
this road less traveled with tools, training, and more 
TLC than FUD. ■ 


Internetworking 

and SNA 

In the next decade, most enterprise networks will be 
based on internetworking. Internetworking is the 
interconnection of individual networks into an 
integrated environment—an internet This technol¬ 
ogy will be the primary foundation for the delivery 
of information between networked systems. 

This article is the introduction to a series which will 
discuss SNA and leading multivendor networking 
protocols, particularly TCP/DP and OSI. The series 
will examine how each developed from a separate 
design philosophy and how they are evolving to 
support internetworking. 

The series will be presented over several months of 
SNA Perspective as a debate, comparing costs and 
benefits of the different approaches. Each install¬ 
ment will note issues that the architectures/proto¬ 
cols must address, changes they must incorporate, 
and their potential areas of convergence. 

The Growth of Internetworking 

Internetworking is fueled by two main driving 
forces. First, cost/performance breakthroughs make 
it economical to place substantial computing power 
on the desktop. Second, development of LAN 
technologies has provided high-speed interconnec¬ 
tion of desktops for workgroup computing. The 
natural next steps for organizations are twofold: to 
connect these separate department or workgroup 
networks into enterprise-wide internets and to 
provide connection to interorganizational networks. 

Advantages 

The advantages of internetworking include the 
ability to: 

• Partition problems 

• Support heterogeneous networks 

• Increase sharing of information and resources 

• Phase in new technologies 
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Partition problems —Internetworking allows an 
organization to take a big, complex problem and 
break it down into smaller, simpler ones. For most 
workgroups, the majority of the information they 
use and share is relevant only to them. Using high¬ 
speed LANs and servers gives desktop systems the 
advantage of local technology. Internetworking 
handles the small percentage of off-site traffic for 
full organizational connectivity. 

Support heterogeneous networks —An internet is 
composed of individual networks which become 
subnets—elements of the larger internet Many 
different types of incompatible networks can be 
combined. Units can choose the appropriate 
technology for their needs without sacrificing 
connectivity to other units. 

Increase sharing of information and resources— 
As more networks are interconnected, the ability to 
share information and resources increases apace. 

Phase in new technologies—The modular nature 
of an internet simplifies technological change. New 
networks can be added and old networks taken out 
of service without a severe impact on the rest of an 
internet. 

Internetworking Challenges 

Organizations considering internetworking must 
consider the challenges as well as the advantages. 
Each area of distinction, highlighted below under 
Distinctions, presents a significant challenge in its 
own right. Each must be solved in relation to the 
others to create an optimum internetworking 
solution. 

Note: In this series, “an internet” is any collection 
of individual networks into an integrated environ¬ 
ment and “the Internet” refers specifically to the 
Internet network developed by the U.S. Defense 
Advanced Research Projects Agency. 

Battle of the Giants 

The Department of Defense Internet, based on the 
TCP/IP protocol suite, has approximately two 
thousand interconnected networks supporting 


350,000 computer systems and well over a million 
users. TCP/IP has undergone extensive refinements 
and enhancements since its development more than 
fifteen years ago. Many organizations have made 
extensive investments in TCP/IP, especially univer¬ 
sities and companies with extensive UNIX environ¬ 
ments. 

In this same time frame, SNA has developed along 
very different lines because it was designed for a 
different purpose. SNA is used as the enterprise 
backbone network for two-thirds of companies with 
such backbones. 

The International Standards Organization devel¬ 
oped the Open Systems Interconnection (OSI) 
reference model in 1978-1984 to serve as a basis 
for developing communications standards within a 
layered context. These standards have been emerg¬ 
ing since the mid-1980s and are referred to as OSI 
standards. However, there are few commercial 
products available based on these standards (except 
that Ethernet and Token-Ring were accepted ex post 
facto as OSI standards). Therefore OSI’s impact is 
measured in terms of potential rather than installa¬ 
tions. (Note: the OSI design at the lower four 
layers evolved more from the TCP/IP model than 
the SNA model; therefore, we use the OSI model to 
compare TCP/IP to the SNA layers.) 

Philosophical Differences 
The development of SNA and TCP/IP was based on 
two different architectural philosophies. Table 1 
shows a qualitative comparison of some of the 
major design goals. 

SNA was developed from IBM’s need for central¬ 
ized, reliable, secure, manageable communications 
for its extensive product line. These capabilities 
were important for IBM’s large business customers, 
which gave SNA a more conservative cast. SNA 
was also particularly focused on terminal-to-host 
communication. Its design assumed and required 
reliable data links and was connection-oriented at 
every level. 

TCP/IP was developed under government contract 
to support system-to-system communication. The 
Internet was intended to encourage the sharing of 
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information by developing an accessible network 
between universities and other research facilities 
under government contract, which gave it a more 
academic flavor. Because it was intended for 
interorganizational sharing, the network was not 
designed to provide security, each site was assumed 
to have installed the security features it wanted for 
access to its systems. TCP/IP was designed so that 
the reliability needed for application communica¬ 
tion did not depend on any particular underlying 
mechanism. Therefore TCP/IP could operate across 
subnetworks with varying qualities of service. 
Lower reliability was not determined to be of such 
critical importance as it was for SNA and business 
communications. Each site managed its own 
portion of the network, and the common carriers, of 
course, managed their environments. TCP/IP 
assumes connectionless interaction at each layer 
and is designed more for file transfer between 
systems than for interactive communications. 

Distinctions 

There are several areas of distinction between SNA 
and the multivendor standards in their approach to 
intemetwoiking issues: 

• Interconnecting subnetworks: bridge, router, or 
brouter 

• Data link layer: spanning tree/transparent 
bridging or source routing 

• Network layer: connectionless or connection- 
oriented 

• Transport layer: where lies the responsibility for 
reliability 

• Network management 

• Addressing: internetwork uniqueness 

• Routing: intradomain, interdomain, and inter- 
internet 

• Infrastructure: native internetworking services 
and sharing the backbone 


Each issue will be considered with regard to SNA, 
TCP/IP, arid OSI. The technical differences in the 
approaches and changes needed in each to support 
effective internetworking will be addressed. 

Summary 

Where you stand depends on where you sit. From 
where the SNA designers sat, the architecture they 
developed met the design criteria for a centralized, 
manageable, secure, and reliable network for 
businesses. For TCP/IP developers, an accessible, 
independent, decentralized network would meet the 
requirements presented to them. 

The world of information systems has changed 
significantly since SNA and TCP/IP were devel¬ 
oped. Each has changed to meet emerging needs in 
different areas. With regard to effectively support¬ 
ing today’s internetworking needs, perhaps SNA 
will have to go through more significant changes 
since TCP/IP was designed with more internet¬ 
working in mind. But TCP/IP, too, has significant 
room to grow in reliability, manageability, and 
security. 

Now the stage is set for this SNA Perspective 
internetworking series. Next month’s installment 
will focus on interconnecting subnetworks and the 
data link and network layers. ■ 
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SNA 5 or New SNA 

by Dr. John R. Pickens 

In the first half dozen years of SNA’s existence, its 
architectual releases were informally identified by 
version numbers. The last release which was given 
a version number was in 1978, SNA Version 4. 
Several years ago, anticipating a new architecture 
update, I queried IBM’s Communications Products 
Division in Raleigh if and when Version 5 was 
expected. The answer? “We don’t talk any longer 
of version numbers.” 

In retrospect, the last release of the full SNA For¬ 
mats and Protocols (SC30-3112) was almost 
exactly ten years ago—at a time when SNA net¬ 
works were still largely hierarchical in nature. So 
should we give up the architecture technology 
search and move on to a more dynamic 
technology—TCP or OSI? 

Actually, SNA has been evolving but in a different 
direction than was originally perceived in the early 
1980s. Driving this evolution is an effort by IBM 
to “plumb” the network landscape with a new 
generation of networking technology featuring a 
common peer-oriented transport substrate and 
common interface subsystems in hosts, midrange 
systems, and personal computers. The basis of this 
new networking substrate? LU 6.2. 

1990 Review 

Looking back, was 1990 was a significant year 
from the perspective of “new SNA”? Yes and no. 

For applications, yes. In 1990, a plethora of LU 
6.2-based applications and interfaces were an¬ 
nounced and delivered. If there were any doubt 
about IBM’s commitment to LU 6.2 for applica¬ 
tions, 1990 eliminated it. 1990 provided the walls 
of new SNA’s house. 


For the SNA backbone foundation, no. Nineteen 
ninety was yet another year of backfilling and 
shoring up its rickety SNA transport environment 
while awaiting the release of new SNA. For 
example, backbone LU 6.2 continues to operate at 
the level of low entry networking (LEN), requiring 
static configuration of just about everything. 
Furthermore, IBM’s backbone networking in 1990 
began to be eroded by an intrusion of layer two 
remote bridging architectures—but that will have to 
be a topic for a future column. The new SNA 
foundation has yet to be laid. 

Predicting New SNA 

Looking back to 1988,1 remember predicting that 
1992 would be the year of the release of a major 
upgrade of SNA architecture. This expected 
upgrade ultimately inherited the name new SNA. 
Looking ahead to 1992, which is now around the 
comer, we can ask several questions. What are the 
important new features of new SNA? Is new SNA 
really coming? 

I claim no insider knowledge of the components of 
new SNA. But many external requirements and 
trends provide strong hints at its new components 
and attributes. Four are especially noteworthy. 

• Enhancements to SNA Layers 1-4 

• Evolution of the LU naming scheme 

• Dynamic name resolution enhancements 

• CMDP rework of SNA/MS 

SNA Layers 1-4 Enhancements 
I expect two key enhancements in SNA’s lower 
layers. First, with the emergence of virtual LAN 
technology in WANs (i.e., frame relay and SMDS), 
a need exists for a reworked architecture within 
SNA’s lower layers. This new architecture would 
provide a greater degree of flexibility toward 
unified support of both LANs and WANs. 

Second, a requirement exists to converge SNA and 
OSI transport There are two reasons for this. First, 
SNA needs to run over OSI connectionless network 
layer services (CNLS). Second, IBM would like its 
networking products to offer CNLS transport to 
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OSI services. In previous Architect’s Comer 
columns, I have discussed IBM’s dual stack strat¬ 
egy toward convergence of OSI and SNA at both 
the bottom and top layers (see November 1989 and 
July 1990 SNA Perspective). 

Evolution of the LU Naming Scheme 

In original SNA, heavy use was made of SNA 
logical units (LUs). Since type 2.0 nodes could 
only support one session per LU, each node was 
defined with multiple LUs, each with a different 
name. 

With APPN, came the first hint that LU naming 
was an evolving concept APPN nodes do not have 
LU names—they have location names. And, 
typically, since NT 2.1 architecture supports 
multiple sessions per LU, only a single location 
name is defined per node. Architecturally, location 
names are still considered LU names. But a defi¬ 
nite trend can be seen toward use of LU naming for 
identification of network nodes, one LU per node. 

Also, new SNA requires a more flexible naming 
scheme. The current NETID.LUNAME [8.8] 
scheme is too restrictive. I’ve suggested in previ¬ 
ous columns a possible convergence here with OSI 
naming and directory services. 

Dynamic Name Resolution Enhancements 

Current published NT 2.1 architecture still requires 
static definition of partner LU Names. In a 10,000 
node network, each node would have to define 
10,000 LU Names—certainly an unacceptable 
situation. 

APPN provided the first insight into how this 
restriction might be removed. APPN contains a 
dynamic registration and discovery protocol. An 
end node can establish a conversation with a 
directory server to perform LU name look up. 


An interesting issue arises in LANs. How does the 
end node find the directory server? What is needed 
is a LAN-level address resolution scheme. 

New SNA will likely contain both types of mecha¬ 
nisms—LU name directory server and LAN layer 
address resolution. 

CMIP Rework of SNA/MS 

Currently, PU type 5 focal points use the network 
management vector transport (NMVT) data struc¬ 
ture for network management. APPN nodes use an 
unpublished management services unit (MSU) for 
network management. LAN Network Manager will 
use CMIP over LLC (CMOL) for network manage¬ 
ment. There are too many network management 
data structure formats. 

Under new SNA, I would expect convergence. As 
discussed in previous columns, this convergence 
will likely be based on the CMIP model. I would 
expect new SNA to feature use of the CMIP model 
for basic network management functions—get, set, 
action, event, create, and delete. 

Summary 

I believe new SNA is around the comer, basically 
on schedule with my original prediction of 1992. I 
also believe that the announcements will occur mid- 
1991 with deliver)' of products in mid- to late-1992. 
Naturally, as is the normal practice for IBM, 
architecture documents for new SNA will not be 
released until the implementing products are 
released. I still believe (see Architect’s Comer in 
January 1989 SNA Perspective) that IBM’s end- 
system-to-intermediate-system protocols will be 
published, while its intermediate-system-to-inter- 
mediate-system protocols will be unpublished. 

The actual functionality remains to be seen. But 
new SNA or SNA 5 or APPN—or whatever the 
name—promises to be a breath of fresh air.B 
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